The 404 path threw a CloudHardError with just the openai_dart
exception message, which loses the actual Azure response body
(`error.message`, `error.code`, `error.type`). Add HarkCloudErr
debug log lines per failure type so first-pass cloud testing can
inspect what Azure actually said.

Also enrich the CloudHardError thrown on 404 with the deployment
name we sent so the user sees what we asked for vs what Azure
couldn't find.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Microsoft surfaces two Azure OpenAI templates in their docs:

- Classic Azure OpenAI Service: api-key: <key> header
- Foundry serverless endpoints: Authorization: Bearer <key> header

Same URL shape, different auth header. The Foundry path is what every
modern model deployment uses (gpt-4.1-mini and friends). Sending
api-key to a Bearer-expecting endpoint returns 404 with body
{error: {code: 404, message: "Resource not found"}} instead of a
clean 401, because the path lookup fails before auth runs.

User reproduced this end-to-end: the Azure portal generated docs for
their hark-cloud-gpt-4-mini deployment use Authorization: Bearer.

Switch the adapter to use ApiKeyProvider (Bearer) for Azure too. The
api-version query parameter is still wired correctly via OpenAIConfig.
The kind dispatch collapses to a single shared branch since all four
OpenAI-compat providers now use the same auth header — kind is still
useful for future per-provider tweaks (Anthropic adapter dispatch,
Gemini-specific quirks).

If a future user has a legacy classic Azure OpenAI deployment that
only accepts api-key, we'll add a UI toggle then. For now the
Foundry-default behavior matches reality.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

The provider-abstraction package was net-negative for our use case:

- We POST one well-known shape per call (chat/completions with tools
  + tool_choice) — no abstraction needed
- Its Azure auth defaults bit us in Slice 5 (AzureApiKeyProvider sent
  api-key header instead of Bearer; mismatched our Foundry serverless
  deployment which expects Authorization: Bearer)
- Even after switching to ApiKeyProvider it still 404'd, masking
  whatever the actual issue is behind a wire format we couldn't
  inspect
- 50KB dependency for what is now a 50-line http POST

Direct http gives us:
- Full visibility on the request bytes (matches the curl Microsoft
  surfaces in their portal verbatim)
- Single code path: same Authorization: Bearer header for OpenAI,
  Azure, Gemini, OpenRouter, custom — every modern OpenAI-compat
  endpoint accepts Bearer
- Tighter URL construction: append /chat/completions to baseUrl by
  string concat (Uri.resolve mishandles per-deployment URLs)
- Simpler error mapping: status code → CloudUnavailableError /
  CloudHardError without translating openai_dart exception types

Anthropic still throws CloudHardError here — Slice 7 gets the
dedicated AnthropicAdapter for the native tool_use shape.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Race condition surfaced in device testing: cloudProviderNotifier.build()
returns a default empty state immediately and kicks off _loadFromStorage()
fire-and-forget. If the first voice command fires before that load
completes — which is the cold-start path when the user goes straight to
a command without opening Settings first — cloudSlotFillerProvider sees
config=null and the resolver routes to local Qwen3.

Earlier "working" runs only worked because the user had opened the
Cloud Brain settings screen first, which warmed the secure-storage
load.

Fix: await CloudProviderNotifier.awaitInitialLoad() at the top of the
resolver's slotFill closure. Idempotent + cached, so the cost is one
secure-storage read on the very first command of a session and zero
thereafter.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>